Protection from Wishful Thinking

ONE OF THE thorny problems of software development is accurately assessing progress and the cost remaining to completion. Without a good sense of where the project is and how far it still has to go, it’s just not possible to consistently manage people and resources well. And miscommunicating progress to stakeholders is among the surest ways to lose trust and buy-in. Despite a plethora of technologies and processes that aim to help teams better assess progress, many software projects still struggle. The complexity of modern systems and the many other day-to-day pressures requiring attention just add to the diffi culty. The temptation to interpret progress measures overoptimistically seems nearuniversal. Optimism is a virtue in many cases, but there is a fi ne (yet important) distinction between optimism and wishful thinking. Finding ways to distinguish the two is an important skill for every member of a development team. Even with the best of intentions and good processes in place, it’s possible for projects to end up in serious trouble as a result of misassessing or miscommunicating progress. To illustrate, let’s look at three examples drawn from real software and systems engineering projects. In each, processes were in place and followed that seemed eminently reasonable for avoiding the worst pitfalls. The teams seem to be playing by the rules, although that might not have been what the projects actually needed. I fi nd that these cautionary tales illustrate some key misconceptions—and can perhaps be useful for refl ecting on whether our own projects are falling into the same traps.